Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix checkout of annotated tag loosing annotation #1506

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Rycieos
Copy link

@Rycieos Rycieos commented Oct 6, 2023

Currently, a check is done after fetch to ensure that the repo state has not changed since the workflow was triggered. This check will reset the checkout to the commit that triggered the workflow, even if the branch or tag has moved since.

The issue is that the check currently sees what "object" the ref points to. For an annotated tag, that is the annotation, not the commit. This means the check always fails for annotated tags, and they are reset to the commit, losing the annotation. Losing the annotation can be fatal, as git describe will only match annotated tags.

The fix is simple: check if the tag points at the right commit, ignoring any other type of object. This is done with the <rev>^{commit} syntax.

From the git-rev-parse docs:

<rev>^{}, e.g. v0.99.8^{commit}
A suffix ^ followed by an object type name enclosed in brace pair means dereference the object at <rev> recursively until an object of type <type> is found or the object cannot be dereferenced anymore (in which case, barf). For example, if <rev> is a commit-ish, <rev>^{commit} describes the corresponding commit object. Similarly, if <rev> is a tree-ish, <rev>^{tree} describes the corresponding tree object. <rev>^0 is a short-hand for <rev>^{commit}.

If the check still fails, we will still reset the tag to the commit, losing the annotation. However, there is no way to truly recover in this situtation, as GitHub does not capture the annotation on workflow start, and since the history has changed, we can not trust the new tag to contain the same data as it did before.

Fixes #290
Closes #697

(I marked this as closing #697 since this fixes the same issue. This fix is better (in my opinion), as this is less of a deviation from the current functionality.)

Currently, a check is done after fetch to ensure that the repo state has
not changed since the workflow was triggered. This check will reset the
checkout to the commit that triggered the workflow, even if the branch
or tag has moved since.

The issue is that the check currently sees what "object" the ref points
to. For an annotated tag, that is the annotation, not the commit. This
means the check always fails for annotated tags, and they are reset to
the commit, losing the annotation. Losing the annotation can be fatal,
as `git describe` will only match annotated tags.

The fix is simple: check if the tag points at the right commit, ignoring
any other type of object. This is done with the <rev>^{commit} syntax.

From the git-rev-parse docs:
> <rev>^{<type>}, e.g. v0.99.8^{commit}
>  A suffix ^ followed by an object type name enclosed in brace pair
>  means dereference the object at <rev> recursively until an object of
>  type <type> is found or the object cannot be dereferenced anymore (in
>  which case, barf). For example, if <rev> is a commit-ish,
>  <rev>^{commit} describes the corresponding commit object. Similarly,
>  if <rev> is a tree-ish, <rev>^{tree} describes the corresponding tree
>  object.  <rev>^0 is a short-hand for <rev>^{commit}.

If the check still fails, we will still reset the tag to the commit,
losing the annotation. However, there is no way to truly recover in this
situtation, as GitHub does not capture the annotation on workflow start,
and since the history has changed, we can not trust the new tag to
contain the same data as it did before.

Fixes actions#290
Closes actions#697
@chrisjenx
Copy link

Not sure on the status of this, but got caught out by this today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Preserve tag annotations
2 participants